本篇是故事四的「理解」篇。

本篇要回答：這場事故裡，工具、規則、流程與人，各自該記哪一筆帳？

當時發生了什麼

事故之後最順口的兩種結論，一種是「這工具有毒，關掉」，另一種是「以後自動修正都不准用」。兩種都是把促成因素誤記成直接原因——工具忠實執行了它的規則，規則忠實反映了一般 Python 的慣例；出事的組合是「通用規則＋不通用語意＋沒有人驗證語意」。

我原本怎麼判斷

我曾把 lint 全綠當成一種背書。拆開看，工具的綠燈證明的是「程式碼更符合工具的規則」，僅此而已；「程式仍然符合系統的語意」從來不在任何工具的保證範圍內——那一塊，從頭到尾都掛在人的名下，只是平常沒人去看那張責任表。

我怎麼查證或重現

三本帳分開記。

直接原因：自動修正改變了 ORM expression 的查詢語意（機制見 Day 18）。

促成因素：

• 把格式化、一般 lint fix 與語意層面的改寫混在同一批操作裡執行。
• 啟用了不安全（unsafe）類的自動修正。
• 自動修改後沒有 review diff——「工具不會錯」的信任跳過了唯一的人工關卡。
• 沒有以查詢結果為斷言的回歸測試，空集合不會讓任何測試轉紅。
• 沒有比對產生的 SQL。
• 把一般 Python 慣例套用到具運算子多載的 ORM／DSL 程式碼上。
• 工具升級後新增或變更規則，專案沒有檢查影響範圍。

系統性缺口：專案沒有區分「工具可以全權處理的區域」與「語意敏感、機器不得單獨改寫的區域」。ORM 查詢、加密邏輯、位元運算——這些地方的字面等價與語意等價經常脫鉤，卻與普通程式碼混在同一條自動化流水線上。

區分證據等級。已確認事實：Day 18 的機制。合理推論：促成因素清單依當時流程複盤。示意內容：語意敏感區域的舉例。

今天留下什麼方法

本篇結論：

工具證明程式碼更符合自己的規則，但沒有人證明它仍然符合系統的語意。

下一篇（Day 20）把三本帳翻成一張自動修正安全檢查表：自動工具可以代替手工，不能代替語意驗證。